Funktionaler Softwaretest für aktive Fahrerassistenzsysteme mittels parametrierter Szenario-Simulation

Im vorliegenden Beitrag wird das Testen der Embedded Software von umfelderfassenden aktiven Fahrerassistenzsystemen mit Hilfe einer bilderzeugenden Sensorstimulation für Hardware-in-the-Loop Testsysteme vorgestellt. Dies ermöglicht quantitative Aussagen zur Erreichen von Qualitätszielen für funktionale Tests mit hoher Testtiefe und –breite. Generierung und Aufbau der relevanten Test-Szenarien wird erläutert. 1 Software im Automobil Moderne Fahrzeuge beinhalten eine Fülle an Software-Komponenten. Diese sind üblicherweise als Embedded Software in Steuergeräten oder vernetzt in Steuergeräteverbünden implementiert (vgl. Abb. 1). Steuergeräte (SG), wie beispielsweise das Motor-SG, die Dachbedieneinheit, das Kombi-Instrument oder multifunktionale „Sensor-Aktor-Module“ kombinieren also Hardware (Sensoren, Aktoren) mit Funktionen, die in Form von Software realisiert sind (vgl. Abb. 2). Dabei sind häufig Echtzeitbedingungen zu erfüllen, um die korrekte Funktion (z.B. eines Airbagsteuergeräts) sicher zu stellen. Aktuelle Oberklassefahrzeuge haben über 80 verschiedene über Busleitungen vernetzte Steuergeräte. Aber nicht nur die Anzahl, auch die Komplexität ihrer Funktionen und damit der ablaufenden Software steigert sich kontinuierlich. Gründe dafür sind wachsende Kundenerwartungen, erhöhte Anforderungen z.B. an Sicherheitsstandards, und auch neue technische Möglichkeiten. [Gr05, Ch09] Embedded Software im Automotive Bereich steht unter dem besonderen Druck, besonders hohe Anforderungen an die Zuverlässigkeit während eines ganzen Autolebens lang, und das unter allen Temperaturund Klimabedingungen und Nutzungsverhalten. Die ständige Interaktion der Software mit den anderen Verkehrsteilnehmern und besonders mit Menschen in ihrer Umgebung legen den benötigten hohen Qualitätsund Sicherheitsstandard fest. Dazu kommen vielfältige verschiedene rechtliche Rahmenbedingungen, die Notwendigkeit einer einfachen Wartbarkeit, das Zusammenspiel von Hardund Software sowie vieler Zulieferer für die einzelnen Elektronik-Komponenten sowie die Notwendigkeit von Ausfallsicherheit und Notlaufkonzepten selbst im Fehlerfall. Abb. 1: Steuergeräte und Datenbusse der Daimler C-Klasse (Baureihe 204). Automotive Software ist also durch hohe Komplexität, komfortund sicherheitsrelevante fahrzeugspezifische Funktionen und daraus resultierend höchste Anforderungen an die Softwarequalität gekennzeichnet. [Li02] 1.1 Aktive Fahrerassistenzsysteme Steuergeräte beinhalten Funktionen zur Entlastung des Fahrers, sei es durch Informationen, Warnungen oder aktive Unterstützung. Erst seit wenigen Jahren gibt es die so genannten Fahrerassistenzsysteme (FAS). Aktive Fahrerassistenzsysteme (engl. Advanced Driver Assistance Systems, ADAS) unterstützen dabei teilweise sogar durch aktive autonome Eingriffe. Beispiele hierfür sind Einparkund Spurhalteassistenten, Fußgängerund Verkehrszeichenerkennung. Diese Systeme greifen im Notfall selbständig durch Lenken oder (Not-) Bremsen direkt in die Längsoder Querregelung des Fahrzeuges ein. Die Umfelderfassung durch Sensoren wie Radar, Video oder Ultraschall ist dabei der übliche Weg, um den Algorithmen Informationen zur Situationsanalyse und –bewertung zu verschaffen. Als Sensordatenfusion bezeichnet man dabei das Vorgehen, immer mehrere Datenquellen redundant zu nutzen, um die Richtigkeit einer Entscheidung genauer abzusichern. Erst wenn Radar-Echos und Videobild unabhängig zum gleichen Analyse-Ergebnis führen, darf das Fahrzeug darauf aktiv reagieren. Abb. 2: Technischer Aufbau eines Steuergeräts als rückgekoppeltes System [Mü07]. Die Sicherheit aller Verkehrsteilnehmer ist das höchste Ziel bei der Entwicklung derart aktiv eingreifenden Funktionen. An die Software dieser Systeme werden aufgrund ihrer möglichen autonomen Aktionen besonders hohe Anforderungen gestellt. Neben einer sorgfältigen und professionellen Softwareentwicklung ist daher auch das Testen der Softwarequalität ein wichtiger Schritt auf dem Weg zum Serieneinsatz eines mit diesen Helfern ausgestatteten Fahrzeugs. 1.2 Heutige Vorgehensweise beim Softwaretest von ADAS Derzeit wird Software und deren Funktionalität in Fahrerassistenzsystemen vielfach durch Testfahrten [ZS08] und einfache Sensorstimulationen getestet. Testfahrten bieten den Vorteil, die reale Umgebung des Einsatzbereichs unter vielfältigsten Bedingungen als „Testdaten“ einzubinden. Damit einher geht der Nachteil, durch viele gefahrenen Kilometer zwar die Anzahl der geprüften Situationen („Use Cases“) zu erhöhen, jedoch lässt sich das Testen damit nicht allumfassend abdecken. Systematik, Automatisierbarkeit, Reproduzierbarkeit und Beeinflussbarkeit der Umgebung sind kaum gegeben, zudem sind aus Sicherheitsgründen viele Testfälle nicht durchführbar. Bei Kamerasystemen kann zum Beispiel das Einspielen von zuvor während realer Fahrten aufgezeichneter Sensordaten (z.B. Radaroder Videodaten) in ein Testobjekt im Labor das Testspektrum erweitern und zu umfassenderen und teilweise genaueren Testergebnissen führen. So können ohne Gefahr und mit beliebigen Wiederholungen vorher aufgenommene und nach Situationen (z.B. Tunnelfahrt, Landstraße, Fußgängerüberweg) klassifizierte Video-Dateien erneut wiedergegeben und damit abgefahren werden. Jedoch zeigen sich auch hier zwei Nachteile: Zum einen bleibt eine Reaktion der Funktion (z.B. Notbremsung) ohne Reaktion auf die Sensoren (das Fahrzeug im Video fährt weiter). Zum anderen ist eine Sensordatenfusion nur dann möglich, wenn alle Sensordaten gleichzeitig in der Realität aufgenommen wurden – oder z.B. manuell in einem Videoobjekt markiert wurden, um daraus künstlich Radarechos zu errechnen. Eine Aussage über den Reifegrad und die Erreichung der Qualitätsziele ist mit beiden Vorgehen nur eingeschränkt und höchstens qualitativ möglich. Auch wenn beide Verfahren ihre Berechtigung haben, so ist doch eine weitere Optimierung der Testverfahren wünschenswert.